Controlling the Target Environment

The first -TENV options are concerned with the shared code model.

-TENV:large_GOT[=(ON|OFF)]

-TENV:small_GOT[=(ON|OFF)]

Shared code and dynamic shared objects (DSOs) require the use of a global offset table (GOT) containing addresses of static data and subprograms at run time. A dedicated register ($gp) points to the GOT at run time, and the code can load these addresses from the GOT without being dependent on its actual virtual address. If the GOT is less than 64KB in size, those loads can all be single instructions; otherwise they require adding a constructed offset to $gp. These options choose one of these cases (the default is small_GOT).

-TENV:large_GOT is a synonym for the compiler option -xgot. For information on gp overflow, see gp_overflow(5).

-TENV:X=n

Specify the level (0 to 5, the default is 1) of enabled traps that are assumed (and enforced) for purposes of performing speculative code motion. At level 0, no speculation is done. At level 1, only safe speculative motion may be done, assuming that the IEEE 754 underflow and inexact traps are disabled. At level 2, all IEEE 754 floating point traps are disabled except divide by zero. At level 3, divide by zero traps are disabled. At level 4, memory traps may be disabled or dismissed by the operating system. At level 5, any traps may be disabled or ignored.

Use nondefault levels with great care. Disabling traps eliminates a useful debugging tool, since the problems that cause them are detected later (often much later) in the execution of the program. In addition, many memory traps can't be avoided outright, but must be dismissed by the operating system after they occur. As a result, level 4 or 5 speculation can actually slow down a program significantly if it causes frequent traps.

Disabling traps in one module requires disabling them for the entire program. Programs that make use of level 2 or above should not attempt explicit manipulation of the hardware trap enable flags. Furthermore, libraries (including DSOs) being built for incorporation in many client programs should generally avoid using this option, since using it makes debugging of the client programs difficult, and can prevent them from safely making use of the hardware trap enables.

-TENV:align_aggregates=n

The ABI specifies that aggregates (that is, structs and arrays) be aligned according to the strictest requirements of their components (fields or elements). Thus, an array of short ints (or a struct containing only short ints or chars) normally is 2-byte aligned. However, some code (non-ANSI conforming) may reference such objects assuming greater alignment, and some code (for example, struct assignments) may be more efficient if the objects are better aligned. This option specifies that any aggregate of size at least n is at least n-byte aligned. It does not affect the alignment of aggregates, which are themselves components of larger aggregates.

-TENV:misalignment=n

This option determines the model the compiler uses in deciding whether or not to assume that the memory references it generates are well aligned. If n=1, it assumes well-aligned references unless it can determine otherwise (except in circumstances like struct copies where the ABI alignment requirements don't normally imply alignment).

If n=2, it always analyzes alignment based on the actual expression used, and trusts casts in the source code to reflect actual alignment. For example, consider the expression:

*(type_a *) &b

The declared type of b implies a certain minimum alignment, as does the cast to type_a; the compiler uses the maximum of the two.

If n=3, the compiler also analyzes alignment, but does not trust casts. In the above example, it assumes the alignment of the declared type of b.